Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-32 < prev next >

Wrap

Text File | 1988-12-01 | 51.5 KB | 2,350 lines

IEN 32 Section 2.3.3.12 Title: Catenet Monitoring and Control: A Model for the Gateway Component Author: John Davidson [Davidson@BBNE] Note: This document contains figures which are not included in this on line version, the figures may be obtained in hardcopy from the author. CATENET MONITORING AND CONTROL: A MODEL FOR THE GATEWAY COMPONENT John Davidson Bolt Beranek and Newman, Inc. IEN #32 Internet Notebook Section 2.3.3.12 April 28, 1978 Catenet Monitoring and Control: A Model for the Gateway Component 1. INTRODUCTION At the last Internet meeting, some concern was expressed that we don't have a real "model" for what a gateway is, what it does, and how it does it, and that without such a model it is somewhat dificult to describe the kinds of activities which should be monitored or controlled by a Gateway Monitoring and Control Center (GMCC). To respond to that concern, we have written this note to express our recent thoughts about a gateway model. Although the note centers primarily around the topic of a gateway model, we have also included a few thoughts about possible models for the other components of a general internetwork structure. The note proceeds as follows. In Section 2 we try to establish a reason for wanting a model of a given internetwork component, and present a brief overview of the potential benefits of Monitoring and Control. This presentation is largely pedagogical since it is assumed that this document will, for a while at least, be the only introduction to the topic available. In Section 3 we discuss the fundamental kinds of activities which must be performed by any internet component if it is to participate in Monitoring and Control. This section establishes motivation for some of the mechanisms discussed in the rest of the paper. - 1 - In Section 4 we discuss the roles which the hosts, local Packet Switching Networks (PSNs), and the Gateway Monitoring and Control Centers (GMCCs) may have to play in Monitoring and Control for the internet. Then, in Section 5, we finally begin to discuss the principle characteristics of a possible gateway model. We examine first a list of practical constraints which influence the way in which the model is being designed, and then, suitably constrained, we begin the task of developing the model itself. A complete modelling has not yet been performed, and is likely to take quite a while to complete. Section 5, however, gives a suitable indication of the way in which the model will be developed, and of the alternative interpretations available to gateway designers who pattern their implementations after the model. - 2 - 2. CONTEXT F OR MODELING It is assumed that gateways exist to make communication possible between hosts on different packet switching networks. In this regard, they actually serve to make a single network out of several diverse, disjoint networks. Thus gateways can be said to form the nodes of a super-network, called a Catenet, whose "links" are the individual packet switching networks, and whose "hosts" are simply the individual hosts of the constituent PSNs. As the nodes of this super-net, the gateways will be responsible in part or in whole for tasks like routing, fragmentation, flow control, reassembly, retransmission, and perhaps data transformation (e.g. encryption/decryption), access control, and even authentication. We can assume that there are benefits to be derived from having the Catenet operate in a coordinated fashion. However, coordination is not achieved by default, because the Catenet is being constructed in pieces, with each piece potentially under the control of a distinct administrator, each gateway implemented in a unique processor, and each program conforming to a different programmer's view of the workings of a gateway. The Internetworking group brought together by ARPA is serving as the coordinating authority for the development of many of the components of the Catenet. To make the important administrative and technical decisions associated with Catenet construction, however, this group must be provided with technical inputs. Many of these inputs can come from theoretical studies, - 3 - protocol investigations, and pre-construction experiments, modeling, and simulation during Catenet development. But the most important source of technical inputs will ultimately be the Catenet itself. If the true operational characteristics of the net can be readily (and continually) determined, then the administrative issues associated with Catenet performance (questions like "why is the throughput not as predicted", "what components are proving unreliable", "should the net be expanded or reconfigured", etc) can be adequately resolved by appeal to the recorded statistics; collection and recording of these operational statistics form a part of what we refer to as Catenet "Monitoring". Also, since the Catenet will sometimes be the "target" of the Internet group or ARPA administrative policy, then, insofar as policy affects the operation of the net (e.g. such "policy" decisions as "failed components should be dumped, reloaded, and restarted ASAP"), technical tools must be provided which help implement the policy; these kinds of tools form a part of what we refer to as Catenet "Control". (Some readers may prefer to think of this as "Coordination" rather than "Control" which unfortunately may carry other undesirable connotations.) In order to be able to Monitor and Control the operation of the Catenet in accordance with administrative policy, in the presence of the diverse component implementations, some model for the network as a whole should be developed. Futher, models for each of the component types (gateways, packet switching nets, hosts) should be developed. These model implementations should then be instrumented in a way that makes it possible to - 4 - accumulate the technical inputs and to effect the operational policy desired by Catenet administrators. If the model implementations are appropriately general, then it is reasonable to dictate that individual implementations adhere to these basic models. BBN is currently pursuing the development of a model for the gateway component of the Catenet. In particular, we are trying to define how the model should be instrumented to provide the appropriate kinds of Monitoring and Control capabilities. Most of the capabilities we think are needed are similar in function to the capabilities already developed for the ARPANET and its Network Control Center, NCC. We are proposing, and in fact have actually begun, the construction of a Gateway Monitoring and Control Center (GMCC) patterned after the NCC (and currently sharing resources with it, since the NCC is already accessible to internetwork traffic and since the scope of the current GMCC is at this time quite modest). - 5 - 3. FUNDAMENTALS OF MONITORING AND CONTROL We assert that all of the Catenet components should be properly instrumented in software (and if necessary, in hardware) to measure the service which the Catenet as a whole provides, and to enhance the maintainability of the net as a whole. The instrumentation should provide us with all the mechanisms required to perform Performance Monitoring Event Recording Functional Testing Component Maintenance Here, by Performance Monitoring, we intend that the status of _______________________ Catenet components (both the binary "working/not-working" indication and the status of internal operational components) be made available to the GMCC. This will require that the Catenet components have a mechanism for communicating periodic status reports and instantaneous error reports "back" to the GMCC. This mechanism may or may not require that the reports from the various net components be synchronized in order to enable the GMCC to obtain a "snapshot" of the network as a whole; if synchronization is required, a synchronizing mechanism will be required as well. It is also undetermined whether a protected path (e.g. one using encryption to prevent spoofing) is required for communicating this information through the Catenet. - 6 - There should also be a mechanism by which the GMCC can request performance data from a Catenet component in the case of non-recurring measurements. The set of monitoring mechanisms installed in any particular component may differ from the set installed in any other component, depending on the granularity of measurement which is desired in each case. By Event Recording, we intend that the raw statistical data _______________ on, say, the number of messages or packets passing through a given component be made available to the GMCC in a standard way. Not only must there be a standard way of collecting the event statistics, but there must also be a way for a designated authority like the GMCC to reset the event counters, say, or turn on or off the event recording mechanisms. We shall have more to say on what events are significant in a subsequent section. By Functional Testing we intend that the GMCC be able to ___________________ direct the activities of the Catenet components either directly (by commanding performance of some task like message generation) or indirectly (by sending, or directing other components to send, messages through a given component) in order to exercise component mechanisms for error analysis or load testing. A useful mechanism in the ARPANET is the ability to isolate failed hardware components by forcing a loopback under software control at each of the component boundaries. The analogue of this scheme in the Catenet is probably simpler, since the boundaries are logically in software (e.g. in the gateway software in cases where a local PSN or another nearby gateway is being tested) or associated with the local PSN which may have reasonably flexible - 7 - control of the interface which connects it to a network host or to a gateway. Looping performed within a component should also be possible. To make use of these testing facilities, we need the ability to generate artificial traffic (and to discard it) and to reflect it (or turn it around) as required. Reflecting messages at gateways can, for example, give a measure of the throughput of Catenet links. By Component Maintenance, we intend that the GMCC have the _____________________ ability to coordinate, and in some cases perform, the analysis of failure for failed components, the restoration of failed components, the institution of program fixes, and the distribution of new releases. It is not clear that Component Maintenance can be the responsibility of just a single GMCC, of course, but if it is to be the responsibility of any GMCC-like component, then the mechanisms by which the failed component is to be handled, and how it is to be of use in the maintenance activity, should be adequately modelled for each component in question. In this regard, we see a potential need for incorporating mechanisms for self diagnosis in the component models, for enabling the GMCC (or some other network host in conjunction with or in place of the GMCC) to read and write arbitrary locations in a component's memory, etc. Note too that the gateway programs will be provided by various implementers. These implementers may in some cases be willing to allow a given GMCC to handle reloads and restarts of - 8 - their component when it fails. Both the implementer and the GMCC staff may have to be involved in debugging the component if the gateway's model debugging facility (which presumes the use of a GMCC) is all the original implementers have for accessing their component remotely. It might prove useful for the GMCC to be able to copy the contents of a failed component into a file for later inspection by the original implementers in case they are unavailable to copy the contents themselves at the time of malfunction. - 9 - 4. MODELS FOR THE PRINCIPLE CATENET COMPONENTS This note is principally about gateway modelling. However, we have asserted throughout, the need to model the other components of the general Catenet as well, so that we can use them in Monitoring and Control applications where they are needed and where they can be useful. Here we describe briefly the goals we have for modelling the other components. 4.1 The GMCC The functions of a GMCC should be able to be performed by any host in the composite net. In view of this, a high level description, or model, of the way a GMCC operates should be created. Both the GMCC program(s) and its data base(s) should be described in a way which allows Catenet users to reproduce the GMCC functions (this basically requires coding of the GMCC programs in a high order language) and to interrogate or duplicate the accumulated data base(s) as required for their own special purposes. Because each gateway, host, or local PSN component of the composite Catenet is potentially the property of a distinct administrative authority, it is conceivable that each might actually be monitored or controlled by a distinct GMCC. This would not necessarily be the best arrangement for purposes of overall net maintainability, but nonetheless must be allowed for. What is more likely, however, is that a given administrator will give permission to some approved Catenet GMCC to perform the Monitoring and Control activities associated with Performance - 10 - Monitoring, say, or with Event Recording, but reserve for itself the ability to perform the activities associated with Functional Testing and Component Maintenance. In this case, the Administrator's host will have to understand and be able to duplicate the model GMCC functions, and the Catenet component will have to know to respond to one or the other GMCC depending on the function being requested. Since different authorities might exist for each different function, this capability should be modelled. Further, the mechanism for changing the name or address of the various designated authorities should also be modelled. Then the fact that each Catenet component knows the name of the authority designated to perform a given function makes it possible to restrict arbitrary hosts from abusing their ability to emulate a GMCC. 4.2 The Hosts Members of the ARPANET NCC staff have asserted that "a key factor in network maintainability is the centralization of the responsibility for providing adequate user service. Since service is best defined at the man/machine interface, a significant gain in maintainability would come about if the user interface were completely at the man/machine boundary. By including a host within the sphere of responsibility of network maintenance, there could be more uniform and speedier resolution of problems within that host. Since the network design allows for dissimilar node programs, not much additional complexity is required to maintain a set of dissimilar service hosts. (Thus) - 11 - the scope of the network should be expanded to providing user services with corresponding benefits for both unified design and maintainability." This may be an extreme position, and may not actually be as easy as anticipated by the NCC staff, but nevertheless it is a position which has at least some validity, especially in view of the fact that gateways are themselves just hosts, and much of the modelling performed for gateways can thus be applied to other general purpose hosts. Consider what Monitoring and Control might be possible if some small component of the host's network software, such as the TCP program, were instrumented to allow Performance Monitoring, Event Recording, etc. under control of a GMCC. The instrumentation would simply provide that the TCP keep track of its events of interest and arrange for them to be made available in a convenient way to some other protocol module (perhaps) for transmission to the GMCC. In addition, if there is to be Control of a TCP, some internal means should be provided for a process to direct certain actions of the TCP (for example the resetting of accounting statistics). Certain other capabilities might also prove useful. The TCP should be able to report to the GMCC any errors it observes in packet formats, packet delivery, etc. so that host personnel with a reliable TCP implementation need not be concerned about error analysis for newly added, undebugged hosts, say. The GMCC is certainly in the appropriate position to be able to correlate abnormal TCP interactions with Catenet component outages and be - 12 - able to explain the abnormal behavior to the host via messages to the TCP. The TCP should be able to be instructed to discard certain messages or to echo them back to their source. It should perhaps be able to timestamp and trace various messages. These kinds of activities would all be possible given an appropriate and uniform instrumentation of the various TCP implementations. 4.3 The PSNs The links of the Catenet are the local PSNs. Unlike usual network links, these links are equipped with a processing capability in the form of their own node computers or their own NCC hosts, etc. Whatever form this processing capability takes, it can presumably be made to communicate with other Catenet components using the protocols for GMCC-to-component and component-to-GMCC communication. The local PSNs should be able to report errors in interfacing which occur at the PSN/gateway interface; they can also report gateway ups and downs as they observe them; they might be instrumented to assist in tracing and looping of messages sent to or through them; they could keep track of the length of gateway outages; and since the PSN is the only component with hardware (in most cases) connections to the gateway and host components, it can perhaps help in the restart or reload of these components. The techniques for performing any of these activities should be carefully and completely modelled. - 13 - 5. A MODEL FOR THE GATEWAY COMPONENT The principle thing we expect a gateway to do is to perform message routing; a suggested routing mechanism is presented in IEN No. 30, "Gateway Routing: An Implementation Specification", by Strazisar and Perlman. Beyond this, there are several secondary activities in which the gateway must play a role, and the large majority of these can be clustered under the general heading of Monitoring and Control. These are the activities we are most concerned with here. As discussed earlier, the gateway component, like any other component, should be instrumented to include mechanisms which allow it to cooperate with a GMCC in providing Performance Monitoring, Event Recording, Functional Testing, and Component (i.e. gateway) Maintenance. It is the role of the model to identify the mechanisms which should be used within the gateway to provide these various functions. 5.1 Considerations Affecting the Design The intent of this section is to give some insight into the process by which the model for the gateway component will be developed. There are a number of fundamental considerations which should be stated beforehand because of their impact on the way we want to think of gateways as an entity and thus on the way we think of the necessarily composed. The first of these is that a gateway should be considered to have a net-independent part and one or more net-dependent parts. The net-independent part should be considered the heart of the gateway -- the place where the - 14 - common functions of routing, flow control, etc. are actually performed; this part is hopefully divorced from considerations of the networks to which the gateway is attached. The net-dependent parts on the other hand may all be different, since the networks in most cases will be different, but each should have the same eessential structure: there will be modules which gate messages to and from the attached net, and modules which append or remove local headers to or from internet (and other) messages, etc. One of the challenges for the model designer and gateway implementer is to carefully design the boundary between the net-dependent and net-independent functions. The gateway model should be able to accommodate more than one type of gateway implementation. That is, it should accurately describe or apply to implementations such as: - the conventional gateway. This is a single processor performing gateway functions only and connected to only two nets. - a two- or multi-processor gateway. This is a distributed implementation of the gateway, such as the "half-gateway" model once considered; the mechanisms used by the separate processors to communicate with each other should not affect the model design. - gateways within general purpose host processors where the gateway program is just one of several that may want access to the network. - gateways connected to three or more networks. - gateways using only a single net interface. Such an arrangement might result if, for example, a single medium were used by two different nets. readdressing, say, .... - both big and small (in terms of power, size, cost, capability) gateways (including very simple - perhaps purely hardware - implementations). - 15 - - existing ARPANET gateways. - existing othernet (sic) gateways. - the gateway module which sits between a host TCP, say, and the network, and whose job it is to select a destination gateway consistent with the destination host. - a gateway with two or more interfaces to a single network. - a gateway which is (either always or sometimes) unwilling or unable to participate in Monitoring and Control exercises. - gateways which are responsible for access control or authentication. The need for these special functions may impact the form of certain mechanisms proposed for use in the model implementation. - gateways which need to perform fragmentation or reassembly of encrypted data messages, or which need to be able to understand special packet formats associated with secure data transmissions. - gateways which may without warning turn into "one-way" paths only for such applications as military EMCON. 5.2 The Beginnings of a Model There are several kinds of information which the gateway should be able to exchange with the GMCC in support of its Monitoring and Control activities. Among them are: Administrative Information This is information that identifies the gateway uniquely among all the components of the composite Catenet. To get a proper picture of the net at any given time, a GMCC would like to be able to discern, among other things, the computer type the memory size the gateway characterization (conventional, ARPANET, ...) the Administrator's name, address, phone number the program size, release number, release date and time - 16 - the addresses of hosts serving as GMCCs the names of connected nets, etc. Information such as this may best be sent unsolicited to a special service host when a gateway first comes up on the net after some outage; interested experimenters could then retrieve the information from the host much as is currently done in the ARPANET for retrieving Host status information. Measurement Information This information is simply the collective set of statistics accumulated by the gateway during its operation. They reflect the processing performed by the gateway in servicing internet traffic. Monitoring Information This is primarily the "up/down", "up for how long", "planned outages", "recent crash explanation", "net interface reset", etc. kinds of information which dictates to the GMCC the status and health of the gateway component. Control Information This is either the information sent by the GMCC to cause the gateway to enter a test, reload, or, restart mode, or the information sent by the gateway to the GMCC to report the results of component testing, to dump some of its memory, etc. Debugging Information Patterned after a general purpose time sharing host's DDT program which has complete control over the execution of subservient programs, the information associated with debugging includes commands to read or write a cell, to set or reset (pseudo) breakpoints, to search memory, etc. and the responses to these commands. Two kinds of DDTs may have to be accommodated in any given gateway implementation, one to be used by experimenters, say, and one, like XNET, to be used during initial debugging. Descriptive Information This is the information which conveys to the GMCC the list of capabilities possessed by the gateway; it includes a listing of the kinds of information collected and reported by the gateway, a characterization of queue capacities, a list of settable operational parameters, a description of the histograms maintained by the gateway, a list of the protocols supported, etc. It responds to the GMCC's questions about "what can you do", "how much can you do", etc. - 17 - Experimental Information This is the information associated with the manipulation of the component by experimenters. It is in part descriptive (experimenters can ask what experiments are supported, what parameters are allowed, what range on parameters is accepted, etc.), in part control (they can request initiation of an experiment), and in part measurement (they can request operational statistics associated with the experiment), but it seems reasonable to distinguish it as distinct from these other operational aspects insofar as possible; not all gateways which provide descriptive, control, and measurement information will also support experimental use. Accounting Information This information is basically the set of raw statistics which should be used by an administrator for charging for gateway utilization. It is reasonable to distinguish this information from pure measurement information since it is not necessarily of interest to a GMCC worrying about functional capabilities, and will likely have to be reported to some special host rather than a general purpose community GMCC. Operational Information This is included here just as a reminder that in addition to manipulating all the information associated with Monitoring and Control activities, the gateway will also want to occassionally handle internet messages, routing messages, and the rest of the information that is its "reason for being" in the first place! Note that it is possible to consider that each individual kind of information is associated with a particular kind of "event" which occurs within a gateway. Thus we may have Measurement events, Monitoring events, and even Administrative events within a functioning gateway. It is also the role of the gateway model to specify how these events are to be recognized, recorded, reported, caused, prevented, suspended, continued, etc. - 18 - At least three notions are central to our discusionss at this point. First, we have the four basic functions that we have discussed in detail before: Performance Monitoring, Event Recording, Functional Testing, and Component Maintenance. From a suitable, high level external viewpoint, these are the functions that the gateway is involved in. Second, we have the different kinds of information which must be recorded by the gateway and transported between the gateway and the GMCC. Each different kind of information implies possibly a distinct formatting requirement, distinct collection mechanism, etc. Finally, there are the several different mechanisms which must exist inside the gateway that can be used to collect, record, and report the different kinds of information. The most apparent mechanisms which exist in the gateway implementations are processes. Processes are the addressable resources which carry on dialogues with the GMCC and with each other in some cases. In addition to the distinct processes, there are other mechanisms which we will just label as "routines". Routines are best thought of as utility functions which may be invoked by any of the gateway processes to help each get its collecting, recording, and reporting done. An example of a utility routine might be one which formats a message according to gateway-to-GMCC protocol specifications and adds it to a queue of messages to be sent. Examples of processes are - the monitoring process which generates the periodic and spontaneous reports to the GMCC describing the operational status of the gateway. - 19 - - the measurement process which delivers cumulative statistics to the GMCC. - the echoing process which returns all received messages to the source from which they originated. - the memory transport process which moves portions of the gateway memory (programs or data) to or from the GMCC. - the terminal handling process which excanges ASCII character streams between the gateway's terminal (if one is present) and a specified internetwork source or destination. - the debugging process. - the message generator process. - etc. It should be obvious that processes do not deal one-to-one with the kinds of information we discussed above. A given process, such as the measurement process, may be used to report the cumulative statistics of each of several kinds of information. Alternatively, it may take more than one process to deal with all the information of any particular kind; for example experimental information as discussed above. And it is certainly likely that multiple distinct processes will have a need to share a single common routine whenever their processing requirements are identical; for example, tracing of messages sent from the GMCC to the debugger, to the echoer, or to the terminal handler should be done by having each process (conceptually) invoke the single trace mechanism. It may also be the case that two processes can be cascaded for the purpose of combining different kinds of information into a single net message. - 20 - 5.3 A Sample Modeling We will develop the gateway model in terms of a general purpose host's implementation, since this allows inclusion of as much mechanism as may be useful for the more general implementation. The figure below shows the principle components of the input handler for a net-dependent part of a general purpose gateway. First there is a hardware component which represents the physical interface between the network and the gateway processor. Obviously this interface will be different for different nets and for different processors, but as a model component should always correspond to some real chunk of hardware in any implementation. Second, there is a piece of code which serves to control the input portion of the net interface hardware. Its basic function is to effect the reading of messages from the network into gateway memory. In the process, it may perform intermediate parsing, do checksum and consistency processing, etc. Third, there is a message queue where unparsed messages reside after they have been received by the net interface routine but before they have been processed by any other gateway routine. This queue may be implemented in any of several ways, and may only have room for a single message in some implementations. (A "higher" level routine may perform queue management in this case, using a different data structure.) - 21 - - 22 - Fourth, there is a second routine depicted whose job it is to parse the received messages one-by-one and distribute them individually to new message queues based on the contents of their local network header. Finally, there are several model components (including both data structures and routines) which are not pictured, but still must be modelled; a subsequent and more complete modelling effort will certainly include them. These are data structures like buffer pools and routines like buffer managers, etc. Associated with these model components are a large number of parameters, both static and operational. These are the things we've been calling "events". In the following we give a sampling of the events of interest for each of the event types we identified before. The sampling is not complete, but it is representative of the kinds of information we might be interested in for purposes of Monitoring and Control in the gateway modelling. Of course, not all of the events are of equal interest or value; as modelers, we should attempt to identify as many as we can, and leave to the individual implementers the selection of which events they really want to record, report, etc. Events of Interest: Administrative - the name and manufacturer of the hardware interface - 23 - Measurement - a histogram of log[base 2] message sizes message counts for each distinct local header type Monitoring - cumulative uptime number of interface errors Control - reset counters place a message on the input queue Debugging - read the hardware status register Descriptive - Fan out for local headers queue size maximum message size Experimental - discard every second message at the interface Accounting - total bits received at the interface 5.4 Continuing the Sample Modeling In this section we continue the sample model introduced above by showing how certain of the data paths might be extended to account for subsequent message processing. It should be easy - 24 - to identify the events of interest in this extension given a little thought. Subsequent attempts at modelling will enumerate these in detail. Note that there are probably several alternative ways of depicting these later stages of message processing; this fact is compounded by the fact that this is the point in message processing where the net-dependent/net-independent boundary may be crossed. Further discussion of alternatives to this part of the model is postponed to the section entitled "Issues". Figure 2 shows the extension to the model. It begins where the previous figure left off. First, note that at this point we have separated the various types of messages arriving at the net interface into unique queues according to indicators in the local header. For this figure we will follow only a single path -- the one followed by internet messages which carry the normal internet traffic. These internet packets are removed from their queue by a routine which separates them again, this time according to the version bit, into a queue of messages which employ the previous internet formatting conventions and a queue of messages which employ the current conventions. From this latter queue, the messages are sent to another routine whose job is to initiate the option processing. In Figure 2, we have represented the options as subroutines without further elaboration; subsequent versions of the model should provide the elaboration. - 25 - - 26 - Finally, after option processing, the messsages are separated again into individual queues according to the values in the protocol field. Here, separate queues may be formed for unrecognized protocols, previous and current versions of TCP, gateway routing messages, and eventually the Monitoring and Control messages, the Datagram Protocol, the Real-Time Protocol, etc. As stated, we will not elaborate here on the events of interest for this part of the model; some should be obvious. - 27 - 5.5 Unresolved Issues In this section we want to address a number of issues which are not yet resolved in the modelling of the gateway component. Their resolution will probably depend on prolonged discussions in certain cases, on snap decisions in others; possibly in some cases a satisfactory resolution will not be possible, and whatever alternative solutions are proposed will all have to be included in a generalized modelling to make sure the modelling is comprehensive enough. At any rate, the topics which need further investigation are presented below. 5.5.1 Are the Event Types Correct First there needs to be some general agreement that the event types (information types) we have identified are sufficient for modelling purposes. It is probably the case that they are correct enough for a beginning, and that no particularly disruptive perturbation of the model would be caused if another event type had to someday be accommodated or an existing event type had to be deleted. However, the omission of an XNET information type (not to be confused with the distinct "debugging" type) may have to be remedied before too long. - 28 - 5.5.2 What Information Should be Communicated to the GMCC Here there is a lot of room for varying opinion. The next cut at the model will try to identify as many potential events of interest as possible. Obviously, not all these events will be of interest to all implementers; that's why the Monitoring and Control mechanisms must be sure to allow for only partial participation on the part of any particular implementation. However, it may also be the case that we omit some event that is of particular interest to some gateway implementer, or the information which we choose to record about the event is not quite what is needed for some implementer's needs. Our collection mechanism must be flexible enough to accommodate extensions at any time. Here the real issue may be how to control, administratively, the selection of events of interest so that all parties are satisfied with the set selected. 5.5.3 How Should Information be Communicated to the GMCC We are of the opinion that in most cases, the basic gateway-to-GMCC communication facility should be datagram oriented on the basis that (1) connection overhead may be too expensive for certain gateway implementations, that (2) no flow control is probably needed since the gateways will not be generating data too frequently and since GMCCs will generally have substantially greater storage and processing capabilities than will the gateways, and that (3) a practical reporting scheme - 29 - can probably be developed in which lost messages will not necessarily represent lost information, merely delayed delivery of information, since the contents of lost messages can be inferred from later messages, (this is the case for cumulative statistics for example); on the other hand, the datagrams should carry sequencing information, and will of course employ standard Internet Headers. Datagram service will be satisfactory in most cases, we hope. In certain instances, however, reliable transmissions may be extremely important; for these instances, some additional capability may have to be added. As yet, we have no real feel for the capabilities required; thus this is still an open issue. Also at issue is the decision as to whether internet messages directed at the various gateway processes should all carry a single protocol designator, or whether each different message type should command a distinct designator. It is not yet clear whether minimal gateway implementations would find it easier to process messages formatted in one way vs. the other, or whether it is too wasteful of the Internet Header's protocol field, or whether it is easier one way or the other to subsequently add or delete new message formats. Beyond these basic issues, there is also the issue of message formats and message content. Two alternatives present themselves as regards event reporting. We assume that event counters can be maintained in 16-bit words, say. We can insist that messages contain a fixed number of counters in a fixed order, and thus eliminate the need to transmit descriptive - 30 - information with each reporting message. Or, we can allow for every counter to be accompanied by another word which names the counter. Tradeoffs between the two strategies are not yet properly understood. 5.5.4 Addressing Processes from Outside the Gateway Each of the gateway processes responsible for some activity of Monitoring and Control has a unique identity, or name, within the Catenet. But because the gateway is attached to multiple nets, it is possible for each process to have multiple distinct addresses. We can assume that one reasonable modelling for the net-dependent input handler requires the input handler to recognize at the net interface all the messages addressed to processes which share its own net (and host) address. This is the case for example in a general purpose implementation of the gateway, since the general purpose input handler doesn't normally receive messages for processes that don't share its own net address. It probably should not be the responsibility of a given net-dependent input handler to be aware that it is playing a role in a gateway implementation, and thus to be cognizant of the alternative internet addresses of the gateway processes it thinks of as its own; i.e. the net-dependent code should not have to know what other nets the gateway is connected to. Therefore, if a message arrives at one net interface that specifies a resource (process) whose net address is different from that of the input handler, then the message should simply be handed off to a - 31 - special process which can effect the proper disposition for the message without further involvement of the input handler. Figure 3 depicts this arrangement. Here, each network has its own interface to a common copy of the gateway process, so that it can communicate with it directly whenever a message arrives which addresses the process via the appropriate net. However, when a message is received for a destination not known to the input handler, the message is simply handed to the special process, which in this figure is referred to as the "Postman". Note that the Postman can effect delivery to the processes via its own interface, so that successful delivery does not depend on the route taken by the message. (Note that the model might want to specify that the Postman be able to add messages to the input queues of the net-dependent input handlers as a means for effecting delivery in a uniform way.) The Postman here also has the responsibility for performing the tasks associated with the routing of messages to distant locations. That is, messages input at the gateway which are only passing through should be routed by the general gateway routing algorithms; these can be implemented by the Postman, or by some other process to which the Postman interfaces. There is, of course, another way to model the net-dependent/net-independent boundary. Figure 4 shows this other way. - 32 - - 33 - - 34 - Basically the difference here is that the net-dependent input handlers no longer have their own interfaces to the gateway processes. Instead, they simply pass all received messages to the internal Postman and allow it to effect delivery. This is an acceptable approach even if in the general purpose host implementation the net-dependent input handlers still have to worry about interfacing processes which aren't using Internet Headers. However, in this model, the Postman and the affected processes must be sure to not lose the destination address by which they were reached, lest they not be able to use the same address for the source in the header of their response messages. (We are somehow assuming that the recipient of a message whose source address does not match the destination address which was used for transmission, will not be anxious to perform the required reverse lookup to map the source address into a resource name. If we were to model this capability, it is not clear where the processing for this lookup would be performed.) At issue here then is just exactly which of these two models should be assumed for "the" model implementation. 5.5.5 Addressing Processes from Inside the Gateway Here is an issue which has certainly been touched on in other internet meetings; it is basically a discussion of the need for high level protocols to carry their own addressing information. - 35 - Gateway processes will have occassion to communicate with other processes in support of gateway routing or gateway Monitoring and Control. Traffic between two gateway processes may be intrahost, intranet, or internet, depending on the relative locations of the source and destination processes. At issue is whether in all cases a single data transport protocol should be used to effect message delivery. We have already "concluded" in the discussion of event reporting that gateway Monitoring and Control messages should employ Internet Headers in all cases. And it would certainly seem on the surface that this scheme is ideal. However, in certain cases this may not be true. We are struck by an inconsistency which arises when we try to attain symmetry in modelling the gateway's internal organization. At one point in the model, we have a process whose job it is to route messages through a given local net. Whenever _________ it is handed an internet message, it analyzes the header of the message in order to determine the desired destination, and hence what local address to specify in the net-dependent data transport protocol. The inconsistency is found because we don't have a corresponding process whose job it is to analyze higher level protocol headers in order to route messages through the internet ________ (using the internet data transport protocol). This means either that each of our Monitoring and Control processes must make up an Internet Header itself, or that, if some common process is to do it, the common process must be handed the addressing information by some "out-of-band" path (such as a shared memory control - 36 - block). This may not be easy to provide for a distributed gateway implementation, say. The real issue here, of course, is inspired by the problems we see for, say, TCP users, if the Internet and TCP Headers recently proposed are adopted for use in the Catenet. The fact that higher level protocols are being designed which don't carry their own addressing information means that these protocols will be practically unusable in any instance where the data transport protocol used to carry the messages is different from the data transport protocol embodied in the Internet Header. TCP, for example, would probably not be usable without Internet Headers in the ARPANET, since port addressing would be impossible. Although it is probably the case that we will not opt to include addressing information in the messages which adhere to our higher level Monitoring and Control protocols, and will thus in fact choose to use the Internet Header to provide addressing, we nevertheless wonder if it is wise to arbitrarily restrict these protocols to use with only a single data transport protocol. - 37 -